Fast and efficient method for deleting very large files from a filesystem

ABSTRACT

In the current invention, a method and apparatus for efficiently deleting large files is described. This is done by having a special inode for pointing to data blocks to be freed, and subsequently freeing the data blocks from the special inode in a controlled manner.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 11/543,826, filed Oct. 6, 2006, entitled “Fast and EfficientMethod for Deleting Very Large Files from a Filesystem,” now allowed,which is a non-provisional of, and claims the benefit of U.S.Provisional Patent Application No. 60/817,533 filed on Jun. 30, 2006,each of which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to data storage, andspecifically to storage of video on a hard disk drive.

2. Background Art

Many users of satellite, cable, or even terrestrial video services haverecently migrated from using analog magnetic media to record programmingto digital video recorders (“DVRs”). DVRs take an input video from avideo source, in digital format or in analog format by first digitizingthe input video, and store the digital video on a fixed medium, such asa hard disk drive (“disk”). A user may subsequently select the recordedvideo for playback, record additional video, or delete the recordedvideo in order to free space in the disk for future recordings.

As High Definition Television (“HDTV”) standards have become more commonin consumer use, DVRs have evolved to record HDTV video. HDTV videoincludes high resolution images that require higher data storage needsfor recording. A typical 2-to-3 hour HDTV recording can occupy a15-to-20 Gigabyte (“GB”) file.

The DVR's disk, used to store recorded content, typically includes acontiguous memory area divided into blocks. Blocks on a disk are thesmallest units in which data are read from and written to the disk. In atypical disk, block sizes are small, usually around 4 kilobytes (“kB”).With a 4 kB block size, a file comprising 7 kB worth of data willconsume 8 kB of disk space, because it will fully consume a 4 kB blockand will consume 3 kB of a second 4 kB block. However, the remaining 1kB on the second block cannot be used to store additional data.

In traditional filesystems, a file's structure is typically kept in aninode. The inode includes pointers to each of the blocks of datanecessary to construct the file. These pointers may include a number ofdirect pointers, which point directly to blocks of the file's data, andsome number of n-way (singly, doubly, etc.) indirect pointers. Indirectpointers are pointers that point to blocks of data that containadditional pointers. For each level of indirect access, there existssuch a set of blocks of data containing additional pointers. At thefinal level of indirect access (the first level for indirect pointers,the second level for doubly indirect pointers, etc.), the pointerscontained within the block of data are direct pointers.

Indirect pointers within an inode exist in order to allow individualfiles to encompass many blocks of data, and therefore allowing for verylarge file sizes. An inode with only direct access pointers wouldrequire the allocation, in advance, of memory for storing directpointers to each block of data of the largest expected file size. Suchan operation is wasteful when allocating smaller files. However,traversing several levels of indirection to access all of the blocks ofdata comprising a larger file is also expensive.

The typical 2-to-3 hour HDTV recording, occupying 15-to-20 GB of diskspace, requires millions of 4 kB blocks to store the recording. Such asmall block size is typically used in order to conserve space on thedisk, as a 20 GB recording may consequently only waste most of a 4 kBblock, an insignificant amount relative to the size of the recording.The drawback of using a small block size is, as noted, the sheerquantity of blocks needed to compose the recording.

A user desiring to delete a recording stored using a small block sizemay find that a typical 15-to-20 GB recording may take several minutesto delete. Prolonged deletion time can be attributed to the organizationof files on a typical disk. In a traditional filesystem employing inodesas discussed above, the inode for a large recording may use a largenumber of n-way indirect pointers in order to provide a reference to therecording's data blocks. When deleting the recording, the filesystem hasto read each pointer that points to valid data and zero them out,requiring a disk write operation to perform the zeroing. For n-wayindirect pointers, the cost of accessing an additional block of data foreach of the n-levels of indirection is added before being able to reachthe recording's requested data block. Accordingly, the time required toperform this process is proportional to accessing the number of blockscomprising a recording times 4 bytes of data (the pointers, one perblock) and writing the pointer back with a null reference.

Furthermore, as noted above, the filesystem may encounter pointers thatrefer to other data structures which in turn contain pointers to blocksof data in the filesystem. It may be possible for the second datastructure to contain references to a third data structure, which in turncontains pointers to blocks of data in the filesystem. Such multiplelevels of indirection in the filesystem generally require several seekoperations by the disk in order to locate the pointed-to data structureand child data structures or blocks of data. With disk seek times of afew milliseconds, accessing and zeroing all of the relevant data for afile may take 10-to-20 seconds per GB.

Accordingly, what is desired is a method for fast and efficient deletionof large files on a disk.

BRIEF SUMMARY OF THE INVENTION

An apparatus includes a CPU and a memory. The memory comprises datablocks, inodes, files, and a garbage collection inode. The files areeach associated with one or more data blocks and an inode. The CPU isoperable to delete a file from the memory by copying the address of thedata blocks associated with the file from the inode associated with thefile to the garbage collection inode. In accordance with an embodimentof the present invention, the memory includes a tangible recordingmedium, such as a hard disk drive.

A file is deleted in a memory by selecting an inode representing thefile to be deleted. A second inode is designated as a garbage collectioninode, wherein the garbage collection inode only points to files to bedeleted. The inode contains an address which represents the location ofa list of pointers to data blocks that compose the file to be deleted.This address is copied to the garbage collection inode. The inode isthen set to no longer point to the location of the list of pointers. Thegarbage collection inode is subsequently traversed and each of the datablocks composing the file to be deleted are freed.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described with reference to the accompanyingdrawings. In the drawings, like reference numbers indicate identical orfunctionally similar elements. Additionally, left-most digit(s) of areference number identifies the drawing in which the reference numberfirst appears.

FIG. 1 illustrates a set-top box operable to perform digital videorecording, in accordance with an embodiment of the present invention.

FIG. 2 illustrates a typical structural organization of data blocks on adisk, in accordance with an embodiment of the present invention.

FIG. 3 illustrates a block bitmap structure, in accordance with anembodiment of the present invention.

FIG. 4 is a flow chart illustrating a method by which a deletionoperation is performed on an inode, in accordance with an embodiment ofthe present invention.

FIG. 5 illustrates a deletion operation performed on an inode, inaccordance with an embodiment of the present invention.

FIG. 6 depicts an example computer system in which the present inventionmay be implemented.

DETAILED DESCRIPTION OF THE INVENTION Digital Video Recorder

FIG. 1 illustrates a digital video recorder (“DVR”) set-top box 100having input video feeds 102 a-102 c and tuners 104. The tuners 104 areconnected through digital transport multiplexers 106 to a CPU 108, amain memory 110, and a disk 112. The digital transport multiplexers arefurther connected to audio/video decoders 114, which in turn areconnected to television monitors 116.

The tuners 104 are operable to select a video feed from a cable feed 102a, a satellite feed 102 b, or a terrestrial feed 102 c. One ofsufficient skill in the relevant arts will recognize that the feeds 102a-102 c could be any other medium of video transmission. The tuners 104provide the selected video to digital transport multiplexers 106. Thedigital transport multiplexers 106 are then operable to transmit theselected video feed to audio/video decoders 114 for display on one ormore television monitors 116.

The digital transport multiplexers 106 can alternatively transmit theselected video feed to a CPU 108 and a main memory 110 for storage in adisk 112. Furthermore, the CPU 108 can transmit a video feed stored ondisk 112 through the main memory 110 to the digital transportmultiplexers 106. The digital transport multiplexers 106 can beinstructed to forward the video feed stored on disk 112 to theaudio/video decoders 114 rather than the selected video feed coming fromtuners 104. In this scenario, the audio/video decoders 114 will decodeand transmit the video feed stored on disk 112 to the televisionmonitors 116 for display.

One skilled in the relevant arts will appreciate that a number ofdifferent memory devices may be used instead of disk 112, including butnot limited to such memory devices not typically used in DVRapplications where the disclosed invention may nevertheless be employed.

Disk Organization

A typical organizational structure for storing data in a disk such asdisk 112 is shown in FIG. 2. A disk 202 can be divided into one or morepartitions 204. Each partition has partition contents 206 which includeinodes 208 and data blocks 210. An individual inode 212 comprises metadata 214, direct block pointers 216, indirect block pointers 218, doublyindirect block pointers 220, and triply indirect block pointers 222. Oneof sufficient skill in the relevant arts will appreciate that thequantity and availability of each kind of n-way indirect block pointersmay vary based on the system, and may include greater or fewer levels ofindirect block access.

An inode 212 comprises meta data 214, used for storing information abouta file, and a series of block pointers. Each of the block pointers inthe inode 212 contain a pointer to a block location within the datablocks 210. The direct block pointers 216 each contain a pointer to ablock location comprising a block of data 224 within data blocks 210.Indirect block pointers 218 contain a pointer to a block locationcomprising a direct block list 226. The direct block list 226 comprisespointers to block locations, each comprising a block of data 224.

Similarly, the doubly-indirect block pointers 220 contain a pointer to ablock location comprising an indirect block list 228, which in turncomprises pointers to block locations comprising direct block lists 226.The direct block lists 226 comprise pointers to block locations, eachcomprising a block of data 224.

Triply-indirect block pointers 222 contain a pointer to a block locationcomprising a doubly-indirect block list 230. The doubly-indirect blocklist 230 comprises pointers to block locations comprising indirect blocklists 228, which in turn operate as detailed above.

In a typical storage system, a single file stored on a disk 202 isassociated with a particular inode 212. If the file size is less thanthe size of a single block, then a single direct block pointer 216 willbe used to point to the single block 224 where the data is placed. Ifthe file is larger, then indirect block pointers are used in order toreference a direct block list 226 containing pointers to multiple datablocks 224.

Assuming a block size of 4 kB and a block list size of 1024 entries, adirect block list 226 contains pointers for 4 MB worth of data blocks224. Accordingly, an indirect block list 228 with 1024 entries containspointers for 1024 direct block lists 226, each comprising pointers for 4MB worth of data blocks 224. Therefore, indirect block lists 228 in atypical system comprises pointers for 4 GB worth of data blocks 224. Ina similar manner, doubly indirect block list 230 comprises 4 TB worth ofdata blocks 224. As a consequence, the singly indirect pointer withinthe inode may point to up to 4 MB of data, the doubly indirect pointer 4GB of data, and the triply indirect pointer 4 TB of data.

Each block pointer may reference any particular 4 kB block on the disk202 without limitation. Accordingly, it is possible for a first datablock 224 referenced within a direct block list 226 to be located at adrastically different location on disk 202 than a second data block 224referenced within the direct block list 226, with both blocks being partof a common file. Because an inode traditionally represents an entiresingle file, blocks located in drastically different locations on diskwill cause slowdowns when attempting to access the file. Therefore, itis desirable to have all of the blocks that form a file to be allocatedcontiguously.

Turning now to FIG. 3, a block bitmap 300 is also present in a typicalfilesystem alongside the inode tree structure. The block bitmap 300contains an entry for each block in the entire filesystem, each entryindicating whether the block is free 302 or used 304. A block is markedas used 304 whenever a direct pointer within an inode as depicted inFIG. 2 points to the block. As one of sufficient skill in the relevantarts will acknowledge, multiple pointers can reference the same block.Accordingly, the block bitmap 300 is sometimes marked with a count ofhow many direct pointers point to the block. When the last directpointer within an inode is zeroed or pointed to a different block, therelevant block is marked as free 302 and may be allocated to a new file.

Garbage Collection Inode

FIG. 4 is a flowchart 400 illustrating the steps by which a garbagecollection inode (“GCI”) may be employed in order to facilitate thedeletion of a file, in accordance with an embodiment of the presentinvention. At step 402, an instruction to delete a particular file isreceived. The instruction contains a unique identifier for the file,such as a file name, in accordance with an embodiment of the presentinvention. Using the unique identifier, the file's associated inode canbe determined at step 404. The inode's data block pointers are copied instep 406 to a GCI, and the pointers are zeroed and the entire inodefreed in step 408. With the data block pointers now located in the GCI,it is possible to iterate through all of the data block pointers in theGCI and mark the data blocks pointed to by each of the data blockpointers as freed in step 410.

In accordance with an embodiment of the present invention, data blockpointers from multiple inodes may be copied, as in step 406, to the GCIbefore previous data block pointers have been completely deleted. Theoperation by which the copying step 406 is performed takes significantlyless time than a deletion operation, in accordance with an embodiment ofthe present invention. Accordingly, several files and their associatedinodes may be marked for deletion through this process by copying thedata block pointers as in step 406 to the GCI in less time than it wouldtake to delete each file using the methods in the prior art.

FIG. 5 compares the operation of a GCI 508 to an inode 502 in accordancewith an embodiment of the present invention. The GCI 508 is aspecially-designated inode with the same structure as a regular inode502. However, the GCI 508 will have its block pointers initially zeroed510, such that the GCI 508 does not represent any area of memory. FIG. 5illustrates, on the left column of the dashed lines 514, the state of aninode 502 to be deleted, and the state of the GCI 508 on the rightcolumn of the dashed lines 514. Both the inode 502 and the GCI 508 areshown prior to deletion 500 along the dashed lines 516, and afterdeletion 512 below the dashed lines 516.

With continued reference to FIG. 4, if a user wishes to delete arecording represented by inode 502, an instruction is provided as instep 402 indicating the recording or file to be deleted. As in step 404,the inode 502 associated with the file is determined. This inode 502contains a pointer to a location A₀ where, for example, a doublyindirect block list 506 is found. The doubly indirect block list 506contains indirect pointers to other lists, and traversing these listseventually leads to the specific data blocks that comprise the recordingrepresented by the inode 502. Traditionally, the filesystem would haveto traverse through each block list to reach each data block, free thepointer referring to the data block, and furthermore mark the pointed-toblock as free in the block bitmap 300 (FIG. 3).

Considering a situation prior to deletion 500 of the recordingrepresented by the inode 502, it is possible to realize a more efficientdeletion operation through the use of the GCI 508. This is accomplishedby transferring the address of a block list pointer 504 from the inoderepresenting the recording to be deleted to the appropriate pointer inthe GCI 508 as in step 406. As indicated in FIG. 5 after deletion 512,the GCI 508 would subsequently contain pointers to the data blocks thatform the to-be-deleted recording. As in step 408, the original inode 502has its pointer to the data blocks that form the to-be-deleted recordingzeroed 510. The inode 502 is now empty. By performing this transfer on apointer to a list of lists of data blocks, the entire recording to bedeleted can be easily transferred to the GCI 508 in only two operations.

The data remains on the disk until the block bitmap 300 (FIG. 3) hasbeen updated such that the data blocks which compose the to-be-deletedrecording are set to a free state 302. This is accomplished as in step410 by iterating through the pointers contained by the GCI 508 andmarking the data blocks pointed to by the pointers as free.

Freeing Disk Blocks

With the blocks to be freed pointed to by the GCI 508, a separateprocess is operable to parse through the GCI 508 to free each of therelevant blocks as in step 410 (FIG. 4), in accordance with anembodiment of the present invention. The separate process may be a lowpriority process in order to free the blocks in the background withoutinterrupting the operation of the DVR 100 (FIG. 1). In accordance withan embodiment of the present invention, the separate process frees thedata blocks pointed to by the GCI 508 by traversing the GCI 508, zeroingthe data block pointers, and marking the relevant block location in theblock bitmap 300 as freed, as in step 410 (FIG. 4). One skilled in therelevant arts will appreciate that any method which can be used todelete an inode may similarly be applied to deletion of the recordingpointed to by the GCI 508.

By deferring the lengthy process of iterating through the data blockpointers in the GCI 508 and freeing the blocks to a separate, lowpriority process, filesystem functionality is not monopolized by thedeletion requests, which otherwise block access to the disk resourcesuntil completed. Accordingly, a DVR 100 implementing this method todelete a recording from a disk 112 will allow a user to perform furtheroperations immediately after requesting the deletion of a recording,rather than having to wait for the deletion to actually complete.

Example Computer System Implementation

Various aspects of the present invention can be implemented by software,firmware, hardware, or a combination thereof. FIG. 6 illustrates anexample computer system 600 in which the present invention, or portionsthereof, can be implemented as computer-readable code. For example, themethod illustrated by flowchart 400 of FIG. 4 can be implemented insystem 600. Various embodiments of the invention are described in termsof this example computer system 600. After reading this description, itwill become apparent to a person skilled in the relevant art how toimplement the invention using other computer systems and/or computerarchitectures.

Computer system 600 includes one or more processors, such as processor604. Processor 604 can be a special purpose or a general purposeprocessor. Processor 604 is connected to a communication infrastructure606 (for example, a bus or network).

Computer system 600 also includes a main memory 608, preferably randomaccess memory (RAM), and may also include a secondary memory 610.Secondary memory 610 may include, for example, a hard disk drive 612and/or a removable storage drive 614. Removable storage drive 614 maycomprise a floppy disk drive, a magnetic tape drive, an optical diskdrive, a flash memory, or the like. The removable storage drive 614reads from and/or writes to a removable storage unit 618 in a well knownmanner. Removable storage unit 618 may comprise a floppy disk, magnetictape, optical disk, etc. which is read by and written to by removablestorage drive 614. As will be appreciated by persons skilled in therelevant art(s), removable storage unit 618 includes a computer usablestorage medium having stored therein computer software and/or data.

In alternative implementations, secondary memory 610 may include othersimilar means for allowing computer programs or other instructions to beloaded into computer system 600. Such means may include, for example, aremovable storage unit 622 and an interface 620. Examples of such meansmay include a program cartridge and cartridge interface (such as thatfound in video game devices), a removable memory chip (such as an EPROM,or PROM) and associated socket, and other removable storage units 622and interfaces 620 which allow software and data to be transferred fromthe removable storage unit 622 to computer system 600.

Computer system 600 may also include a communications interface 624.Communications interface 624 allows software and data to be transferredbetween computer system 600 and external devices. Communicationsinterface 624 may include a modem, a network interface (such as anEthernet card), a communications port, a PCMCIA slot and card, or thelike. Software and data transferred via communications interface 624 arein the form of signals which may be electronic, electromagnetic,optical, or other signals capable of being received by communicationsinterface 624. These signals are provided to communications interface624 via a communications path 626. Communications path 626 carriessignals and may be implemented using wire or cable, fiber optics, aphone line, a cellular phone link, an RF link or other communicationschannels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage unit 618, removable storage unit 622, a hard disk installed inhard disk drive 612, and signals carried over communications path 626.Computer program medium and computer usable medium can also refer tomemories, such as main memory 608 and secondary memory 610, which can bememory semiconductors (e.g. DRAMs, etc.). These computer programproducts are means for providing software to computer system 600.

Computer programs (also called computer control logic) are stored inmain memory 608 and/or secondary memory 610. Computer programs may alsobe received via communications interface 624. Such computer programs,when executed, enable computer system 600 to implement the presentinvention as discussed herein. In particular, the computer programs,when executed, enable processor 604 to implement the processes of thepresent invention, such as the steps in the method illustrated byflowchart 400 of FIG. 4 discussed above. Accordingly, such computerprograms represent controllers of the computer system 600. Where theinvention is implemented using software, the software may be stored in acomputer program product and loaded into computer system 600 usingremovable storage drive 614, interface 620, hard drive 612 orcommunications interface 624.

The invention is also directed to computer products comprising softwarestored on any computer useable medium. Such software, when executed inone or more data processing device, causes a data processing device(s)to operate as described herein. Embodiments of the invention employ anycomputer useable or readable medium, known now or in the future.Examples of computer useable mediums include, but are not limited to,primary storage devices (e.g., any type of random access memory),secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIPdisks, tapes, magnetic storage devices, optical storage devices, MEMS,nanotechnological storage device, etc.), and communication mediums(e.g., wired and wireless communications networks, local area networks,wide area networks, intranets, etc.).

CONCLUSION

Example embodiments of the methods, systems, and components of thepresent invention have been described herein. As noted elsewhere, theseexample embodiments have been described for illustrative purposes only,and are not limiting. Other embodiments are possible and are covered bythe invention. Such other embodiments will be apparent to personsskilled in the relevant art(s) based on the teachings contained herein.Thus, the breadth and scope of the present invention should not belimited by any of the above-described exemplary embodiments, but shouldbe defined only in accordance with the following claims and theirequivalents. Furthermore, the disclosed data storage techniques are notlimited to any particular memory device or those commonly used in DVRapplications.

1. A digital video recorder comprising: a processor; and a memory,comprising: a first target file associated with one or more first datablocks and with a first file record; a second target file associatedwith one or more second data blocks and with a second file record; and asingle garbage collection file record, wherein the garbage collectionfile record is configured to only point to data blocks of files markedfor deletion; wherein the processor is configured to: copy an address ofthe one or more first data blocks associated with the first target file,from the first file record associated with the first target file, to thegarbage collection file record, copy an address of the one or moresecond data blocks associated with the second target file, from thesecond file record associated with the second target file, to thegarbage collection file record, and traverse the garbage collection filerecord and free the data blocks of the files marked for deletion.
 2. Thedigital video recorder of claim 1, wherein the first target filecomprises a video feed.
 3. The digital video recorder of claim 1,further comprising: a tuner, wherein the tuner is configured to transmita video feed to the processor, and wherein the processor is furtherconfigured to store the video feed to the first target file.
 4. Thedigital video recorder of claim 1, wherein the processor is furtherconfigured to perform additional operations while the traversing thegarbage collection file record and the freeing the data blocks of thefiles marked for deletion occurs in the background.
 5. The digital videorecorder of claim 1, wherein the memory comprises a fixed recordingmedium.
 6. The digital video recorder of claim 5, wherein the fixedrecording medium comprises a hard disk drive.
 7. A method comprising:copying an address of one or more first data blocks associated with afirst target file, from a first file record associated with the firsttarget file, to a single garbage collection file record, wherein thegarbage collection file record is configured to only point to datablocks of files marked for deletion; copying an address of one or moresecond data blocks associated with a second target file, from a secondfile record associated with the second target file, to the garbagecollection file record; and traversing the garbage collection filerecord and freeing the data blocks of the files marked for deletion. 8.The method of claim 7, wherein the copying comprises: copying anindirect block pointer within the first file record associated with thefirst target file to the garbage collection file record, wherein theindirect block pointer points to an indirect block comprising a list ofpointers to a set of blocks.
 9. The method of claim 7, wherein thecopying comprises: copying a doubly indirect block pointer within thefirst file record associated with the first target file to the garbagecollection file record, wherein the doubly indirect block pointer pointsto a doubly indirect block comprising a list of pointers to a set ofindirect blocks, the set of indirect blocks comprising a list ofpointers to a set of blocks.
 10. The method of claim 7, furthercomprising: performing additional operations while the traversing of thegarbage collection file record and the freeing of the data blocks of thefiles marked for deletion occurs in the background.
 11. The method ofclaim 7, further comprising: receiving a video feed; and storing thevideo feed to the first target file.
 12. The method of claim 11, furthercomprising: directing the first target file to one or more decoders foroutput to a display.
 13. A computer-readable storage medium havingcomputer program logic recorded thereon that, when executed by aprocessor, causes the processor to perform a method, the methodcomprising: copying an address of one or more first data blocksassociated with a first target file, from a first file record associatedwith the first target file, to a single garbage collection file record,wherein the garbage collection file record is configured to only pointto data blocks of files marked for deletion; copying an address of oneor more second data blocks associated with a second target file, from asecond file record associated with the second target file, to thegarbage collection file record; and traversing the garbage collectionfile record and freeing the data blocks of the files marked fordeletion.
 14. The computer-readable storage medium of claim 13, whereinthe copying comprises: copying an indirect block pointer within thefirst file record associated with the first target file to the garbagecollection file record, wherein the indirect block pointer points to anindirect block comprising a list of pointers to a set of blocks.
 15. Thecomputer-readable storage medium of claim 13, wherein the copyingcomprises: copying a doubly indirect block pointer within the first filerecord associated with the first target file to the garbage collectionfile record, wherein the doubly indirect block pointer points to adoubly indirect block comprising a list of pointers to a set of indirectblocks, the set of indirect blocks comprising a list of pointers to aset of blocks.
 16. The computer-readable storage medium of claim 13, themethod further comprising: performing additional operations while thetraversing of the garbage collection file record and the freeing of thedata blocks of the files marked for deletion occurs in the background.17. The computer-readable storage medium of claim 13, the method furthercomprising: receiving a video feed; and storing the video feed to thefirst target file.
 18. The computer-readable storage medium of claim 17,the method further comprising: directing the first target file to one ormore decoders for output to a display.